app/Services/Utils/LockManagerService.php (1)

62-70: 💤 Low value

Minor: Unnecessary sleep before throwing on final retry.

When attempt >= MaxRetries - 1, the code still executes usleep before throwing. This adds ~400ms of unnecessary delay on the final failed attempt.

Consider moving the retry check before the sleep:

Suggested reorder

-        $wait_interval = (int)(self::BackOffBaseInterval * (self::BackOffMultiplier ** $attempt));
-        Log::debug(sprintf("LockManagerService::acquireLock name %s retrying in %s µs (attempt %s)", $name, $wait_interval, $attempt));
-        usleep($wait_interval);
         if ($attempt >= (self::MaxRetries - 1)) {
             Log::error(sprintf("LockManagerService::acquireLock name %s lifetime %s ERROR MAX RETRIES attempt %s", $name, $lifetime, $attempt));
             throw new UnacquiredLockException(sprintf("lock name %s", $name));
         }
+        $wait_interval = (int)(self::BackOffBaseInterval * (self::BackOffMultiplier ** $attempt));
+        Log::debug(sprintf("LockManagerService::acquireLock name %s retrying in %s µs (attempt %s)", $name, $wait_interval, $attempt));
+        usleep($wait_interval);
         ++$attempt;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Services/Utils/LockManagerService.php` around lines 62 - 70, The loop in
LockManagerService::acquireLock sleeps (usleep) even when $attempt >=
(self::MaxRetries - 1), causing an unnecessary delay before throwing
UnacquiredLockException; reorder the logic so the check for final retry (if
$attempt >= (self::MaxRetries - 1)) occurs before calling usleep and before
incrementing $attempt, log and throw immediately on final attempt, otherwise
perform the usleep, increment $attempt and continue the loop to preserve backoff
behavior.

tests/Unit/Services/LockManagerServiceOwnershipTest.php (1)

139-144: 💤 Low value

Consider asserting the token is non-empty for stronger ownership guarantee coverage.

Mockery::type('string') accepts any string including ''. A complementary assertion with Mockery::on(fn($v) => strlen($v) >= 16) (or similar) would confirm the service is actually generating a meaningful random token rather than an empty or trivial value.

♻️ Tighter token constraint

-              ->with('test.lock', Mockery::type('string'), 3600)
+              ->with('test.lock', Mockery::on(fn(string $v) => strlen($v) >= 16), 3600)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Unit/Services/LockManagerServiceOwnershipTest.php` around lines 139 -
144, Replace the loose Mockery::type('string') expectation in
LockManagerServiceOwnershipTest (the mock of ICacheService used with
addSingleValue) with a stricter constraint that asserts the token is
non-empty/strong (e.g. Mockery::on(fn($v) => is_string($v) && strlen($v) >= 16))
or add an additional expectation using Mockery::on to verify token length,
keeping the same call to addSingleValue and the deleteIfValueMatches
expectation; target the mock for addSingleValue on the ICacheService to ensure
the generated token is meaningful rather than allowing an empty string.

tests/Unit/Services/LockManagerServiceOwnershipTest.php (1)

139-145: ⚡ Quick win

Assert token identity across acquire and release, not just token type.

At Line [142] and Line [144], the test validates string token creation and release call count, but it does not verify deleteIfValueMatches receives the same token captured during addSingleValue. A token-mismatch regression could still pass.

Proposed test hardening

     public function testAddSingleValueCalledOnceWithTokenAndLifetime(): void
     {
         $cache = Mockery::mock(ICacheService::class);
+        $token = null;
         $cache->shouldReceive('addSingleValue')
               ->once()
-              ->with('test.lock', Mockery::type('string'), 3600)
+              ->with(
+                  'test.lock',
+                  Mockery::on(function ($value) use (&$token) {
+                      if (!is_string($value) || $value === '') return false;
+                      $token = $value;
+                      return true;
+                  }),
+                  3600
+              )
               ->andReturn(true);
-        $cache->shouldReceive('deleteIfValueMatches')->once()->andReturn(true);
+        $cache->shouldReceive('deleteIfValueMatches')
+              ->once()
+              ->with('test.lock', Mockery::on(fn($value) => $value === $token))
+              ->andReturn(true);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Unit/Services/LockManagerServiceOwnershipTest.php` around lines 139 -
145, The test currently only asserts the token is a string and that
deleteIfValueMatches is called, but not that it's the same token; update
LockManagerServiceOwnershipTest to capture the token passed to
ICacheService::addSingleValue (use Mockery capture or an on/closure) and then
assert ICacheService::deleteIfValueMatches is invoked with the same captured
token (e.g., expect deleteIfValueMatches('test.lock', <capturedToken>)). Keep
addSingleValue and deleteIfValueMatches expectations tied to the captured
variable so the test fails on token mismatches.